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Dear Paul, 



Mew Patent Applications: MEDIIAIHBGlHWAY-> 

Find enclosed a copy of the document "Gestionnaire de fichier en FLASH" prepared by Hongtao 
Liao concerning memory management in the MEDIAHIGHWAY+ system together with extracts 
from the document "Conception du systeme Middleware". There seem to me to be two main areas 
bf interest that could form the subject of a patent application. 



1. Flash [Memory Management (Sections 1,1 to 1,2.1) 

The present system (described in M&S 19889 and section 1.1.2 of this document) uses a 
combination of RAM, EEPROM and FLASH memory to write and delete pages in the FLASH 
memory. 

The new system takes advantage of the organisation of data in separately accessible blocks in the 
memory and also relies on the fact that whilst writing in the FLASH memory (i.e. changing a bit 0 to 
a bit 1) requires changing the state of a complete page, deletion of a bit (bit 1 to bit 0) may be 
carried out individually, without rewriting a whole page. 

Sections 1 .1.3 to 1.2.1 and Figure 1 describe the process. 
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Each page in the FLASH memory contains one or more blocks of information, each block including 
an ID value and a valid/invalid indicator (1 or 0). When it is desired to replace a block of 
information, the new valid block is simply written in the page after the other blocks. The 
valid/invalid indicator in the old block is then set to zero (invalid). At this time the old block of data 
is not deleted but co-exists with the new valid block. Any application accessing the data will only 
read the valid block. 

The FLASH memory includes a buffer page. When all the other pages are saturated, a decision is 
taken to copy (via RAM) the valid contents of a page into the buffer page. This source page may 
be, for example, chosen to be the page with the highest number of invalid blocks of data. Only the 
valid blocks of data are copied over. The entire source page is then deleted and becomes the new 
buffer page. 

Unlike the M&S 19889 system, there is no need for an EEPROM memory to monitor the state of 
the stored data. Furthermore, the deletion of the source page to create a new buffer page is 
carried out well in advance of the writing of information to the buffer, leading to a reduction in 
processing time. The fact that data is copied in blocks also means that the size of the RAM used 
in this process need only be as large as a block of data (and not as large as a whole page of 
FLASH memory). 



2. Directoiry and File Structure of Date in Memory (Sections 1.2.2 to 1.2.3) . 

Unlike the memory organisation in MEDIAHIGHWAY, which uses a single level of hierarchy, the 
new system divides data across all memory volumes (RAM, ROM, FLASH etc.) into a series of 
directories and files. Figures 1, 4 and 5 of the document "Conception du systeme Middleware" 
show the global perspective. Section 1 .2.2 to 1 .2.3 and Figure 2 of the document "Gestion de 
fichier en Flash" describe the structure of a given file or directory as stored (in this example) in the 
FLASH memory. 

The general concept of organisation of data in directories and files is of course known from the PC 
domain. As a first position we could, of course, try to claim this structure in relation to an IRD 
memory environment, but I would expect a fairly well-founded obviousness objection from an 
examiner. 

Aside from this aspect, there are a number of characteristics of the MEDIAHIGHWAY+ file system 
more specific to the requirements of IRDs and that seem worthy of protection. In particular, in 
addition to the ID and Father ID fields used to trace the arborescence of a file, the header of a 
block of data also includes the fields "Owner", "Group" and "Access mode". See Figure 2. 

The owner/group fields enable the system to distinguish between data associated with, for 
example, the system owner (such as Canal+) and the users of a system (CanalSatellite, BDB etc.). 
The fields may of course be used to distinguish between owners and users of data at other levels 
within the broadcasting hierarchy. The access mode field enables a block of data to include an 
indicator of the person or persons (owner, group or other) authorised to read and/or write data in 
relation to a given block. 

With the increasing pressure to integrate multiple systems in a single decoder, the ability to 
securely segregate data within the decoder is becoming more and more important. 
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Please let rne know as soon as possible how you wish to proceed, i.e. whether you or Andy wish to 
interview Hongtao before and/or after preparation of a first draft, and the rough time scale for 
preparing the application. 

Best regards, 



Dave HAWKES 



End. 
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